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Abstract 


This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e" 
(6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables 
distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes 
to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one 
another. 6P is part of the 6TiSCH Operation Sublayer (6top), the 
layer just above the IEEE Std 802.15.4 TSCH Medium Access Control 
layer. 6top is composed of one or more Scheduling Functions (SFs) 
and the 6top Protocol defined in this document. A 6top SF decides 
when to add/delete cells, and it triggers 6P Transactions. The 
definition of SFs is out of scope for this document; however, this 
document provides the requirements for an SF. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8480. 
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This document is subject to BCP 78 and the IETF Trust's Legal 
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(https://trustee.ietf.org/license-info) in effect on the date of 
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1. Introduction 

All communication in an "IPv6 over the TSCH mode of IEEE 802.15.4e" 

(6TiSCH) network is orchestrated by a schedule [RFC7554]. The 

Schedule is composed of cells, each identified by a 

[slotOffset,channelOffset (Section 3.2.4). This specification 


defines the 6TiSCH Operation Sublayer (6top) Protocol 
terminated by 6top. 6P allows a node to communicate with a neighbor 
node to add/delete Time-Slotted Channel Hopping 


one another. 
6TiSCH network. 
(SFs) 


This results 


and the 6top Protocol 
of SFs is out of scope for this document; 


provides the requirements for an SF. 


Wang, 


et al. 


Standards Track 


however, 


(TSCH) 


(6P), which is 


cells to/on 


in distributed schedule management in a 
6top is composed of one or more Scheduling Functions 
defined in this document. 


The definition 


this document 
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The example network depicted in Figure 1 is used to describe the 
interaction between nodes. We consider the canonical case where 
node "A" issues 6P Requests (also referred to as "commands" in this 
document) to node "B". We use this example throughout this document: 
node A always represents the node that issues a 6P Request, and 

node B represents the node that receives this request. 


(R) 
IN 


Figure 1: A Simple 6TiSCH Network 


We consider that node A monitors the communication cells it has in 
its schedule to node B: 


o If node A determines that the number of link-layer frames it is 
sending to node B per unit of time exceeds the capacity offered by 
the TSCH cells it has scheduled to node B, it triggers a 6P 
Transaction with node B to add one or more cells to the TSCH 
Schedule of both nodes. 


o If the traffic is lower than the capacity offered by the TSCH 
cells it has scheduled to node B, node A triggers a 6P Transaction 
with node B to delete one or more cells in the TSCH schedule of 
both nodes. 


o Node A MAY also monitor statistics to determine whether collisions 
are happening on a particular cell to node B. If this feature is 
enabled, node A communicates with node B to "relocate" this 
particular cell to a different [slotOffset,channelOffset] location 
in the TSCH schedule. 


This results in distributed schedule management in a 6TiSCH network. 


The 6top SF defines when to add/delete a cell to/on a neighbor. 
Different applications require different SFs; this topic is out of 
Scope for this document. Different SFs are expected to be defined in 
future companion specifications. A node MAY implement multiple SFs 
and run them at the same time. At least one SF MUST be running. The 
SFID field contained in all 6P messages allows a node to invoke the 
appropriate SF on a per-6P Transaction basis. 
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Section 2 describes 6top. Section 3 defines 6P. Section 4 provides 
guidelines on how to define an SF. 


1.1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 


"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


2.  6TiSCH Operation Sublayer (6top) 


As depicted in Figure 2, 6top is the layer just above the IEEE Std 


802.15.4 TSCH Medium Access Control (MAC) layer [IEEE802154]. We use 
"802.15.4" as a short version of "IEEE Std 802.15.4" in this 
document. 


higher layers 


IEEE Std 802.15.4 TSCH 


Figure 2: 6top in the Protocol Stack 
The roles of 6top are to: 


o Terminate 6P, which allows neighbor nodes to communicate to 
add/delete cells to/on one another. 


o Run one or multiple 6top SFs, which define the rules that decide 
when to add/delete cells. 
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2.1. Hard/Soft Cells 
Each cell in the schedule is either "hard" or "soft": 


O A soft cell can be read, added, deleted, or updated by 


o A hard cell is read-only for 6top. 


6top. 


In the context of this specification, all the cells used by 6top are 
Soft cells. Hard cells can be used, for example, when "hard-coding" 


a schedule [RFC8180]. 
2.2. Using 6P with the Minimal 6TiSCH Configuration 


6P MAY be used alongside the minimal 6TiSCH configuration 
In this case, it is RECOMMENDED to use two slotframes, as 


[RFC8180]. 
depicted in 


Figure 3: 

o Slotframe 0 is used for traffic defined in the minimal 6TiSCH 
configuration. In Figure 3, Slotframe 0 is five slots long, but 
it can be shorter or longer. 

o 6P allocates cells from Slotframe 1. In Figure 3, Slotframe 1 is 
10 slots long, but it can be shorter or longer. 

0 1 2 3 a (O°) il 2 3 4 
HS === 222222 += === == 223222220 >3==P?93555 + 
Slotframe 0 
5 slots long EB EB 
(Minimal 6TiSCH) | | | | | | | | 
E SSS Sa SS eS o ecc + 
0 1 2 3 4 5 6 7 8 9 
SS a es ee + 
Slotframe 1 | | | | | | | | | 
10 slots long | A->B | | | | | | | B->A | 
(6P) | | | | | | | | | 
Posse SSR SSS a SSeS SSS SS SS SSS SS Se SSS SSeS + 


Figure 3: 2- 


Slotframe Structure when Using 6P alongside the 
Minimal 6TiSCH Configuration 


The minimal 6TiSCH configuration cell SHOULD be allocated from a 
slotframe of higher priority than the slotframe used by 6P for 
dynamic cell allocation. This way, dynamically allocated cells 


cannot "mask" the cells used by the minimal 6TiSCH configuration. 


6top MAY support additional slotframes; how to use additional 


slotframes is out of scope for this document. 
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3. 6top Protocol (6P) 


6P enables two neighbor nodes to add/delete/relocate cells in their 
TSCH schedule.  Conceptually, two neighbor nodes "negotiate" the 
location of the cells to add, delete, or relocate in their TSCH 
Schedule. 


3.213 6P Transactions 


We call "6P Transaction" a complete negotiation between two neighbor 
nodes. A particular 6P Transaction is executed between two nodes as 
a result of an action triggered by one SF. For a 6P Transaction to 
succeed, both nodes must use the same SF to handle the particular 
transaction. A 6P Transaction starts when a node wishes to 
add/delete/relocate one or more cells with one of its neighbors. A 
6P Transaction ends when (1) the cell(s) has been added/deleted/ 
relocated in the schedule of both nodes or (2) the 6P Transaction has 
failed. 


6P messages exchanged between nodes A and B during a 6P Transaction 
SHOULD be exchanged on non-shared unicast cells ("dedicated" cells) 
between nodes A and B. If no dedicated cells are scheduled between 
nodes A and B, shared cells MAY be used. 


Keeping consistency between the schedules of the two neighbor nodes 
is important. A loss of consistency can cause loss of connectivity. 
One example is when node A has a transmit cell to node B but node B 
does not have the corresponding reception cell. To verify 
consistency, neighbor nodes maintain a sequence number (SeqNum). 
Neighbor nodes exchange the SeqNum as part of each 6P Transaction to 
detect a possible inconsistency. This mechanism is explained in 
Section 3.4.6.2. 


An implementation MUST include a mechanism to associate each 
Scheduled cell with the SF that scheduled it. This mechanism is 
implementation specific and is out of scope for this document. 


A 6P Transaction can consist of two or three steps. A 2-step 
transaction is used when node A selects the cells to be allocated. A 
3-step transaction is used when node B selects the cells to be 
allocated. An SF MUST specify whether to use 2-step transactions, 
3-step transactions, or both. 


We illustrate 2-step and 3-step transactions using the topology in 
Figure 1. 


Wang, et al. Standards Track [Page 7] 


RFC 8480 6top Protocol (6P) November 2018 


3.1.1. 2-Step 6P Transaction 


Figure 4 shows an example 2-step 6P Transaction. In a 2-step 
transaction, node A selects the candidate cells. Several elements 
are left out so that the diagram is easier to understand. 


6P ADD Request 


Type = REQUEST 
Code = ADD 
SegNum = 123 
cells NumCells = 2 
locked CellList = [(1,2), (2,2), (3, 5)] 
+--  |-2------------------------------------- > 
L2 ACK 
OP“ Timeout, E PO AA A PA AA SR, ERU 
| 
| 6P Response 
Type = RESPONSE 
Code = RC_SUCCESS 
| SeqNum = 123 cells 
| CellList = [(2,2), (3,5)] locked 
+—> X A a --+ 
L2 ACK | 
------------------- >| <-+ 


Figure 4: An Example 2-Step 6P Transaction 
In this example, the 2-step transaction occurs as follows: 


1. The SF running on node A determines that two extra cells need to 
be scheduled to node B. 


2. The SF running on node A selects candidate cells for node B to 
choose from. Node A MUST select at least as many candidate cells 
as the number of cells to add. Here, node A selects three 
candidate cells. Node A locks those candidate cells in its 
Schedule until it receives a 6P Response. 
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Wang, 


Node A sends a 6P ADD Request to node B, indicating that it 
wishes to add two cells (the "NumCells" value) and specifying the 
list of three candidate cells (the "CellList" value). Each cell 
in the CellList is a [slotOffset,channelOffset] tuple. This 6P 
ADD Request is link-layer acknowledged by node B (labeled "L2 
ACK" in Figure 4). 


After having successfully sent the 6P ADD Request (i.e., 
receiving the link-layer acknowledgment), node A starts a 6P 
Timeout to abort the 6P Transaction in the event that no response 
is received from node B. 


The SF running on node B selects two out of the three cells from 
the CellList of the 6P ADD Request. Node B locks those cells in 
its schedule until the transmission is successful (i.e., node B 
receives a link-layer ACK from node A). Node B sends back a 6P 
Response to node A, indicating the cells it has selected. The 
response is link-layer acknowledged by node A. 


Upon completion of this 6P Transaction, two cells from node A to 
node B have been added to the TSCH schedule of both nodes A 
and B. 


An inconsistency in the schedule can happen if the 6P Timeout 
xpires when the 6P Response is in the air, if the last 
link-layer ACK for the 6P Response is lost, or if one of the 
nodes is power-cycled during the transaction.  6P provides an 
inconsistency detection mechanism to cope with such situations; 
see Section 3.4.6.2 for details. 
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3.1.2. 3-Step 6P Transaction 


Figure 5 shows an example 3-step 6P Transaction. In a 3-step 
transaction, node B selects the candidate cells. Several elements 
are left out so that the diagram is easier to understand. 


6P ADD Request 


Type = REQUEST 
Code — ADD 
SeqNum = 178 
NumCells = 2 
CellList zu 
————————————————————————————————————— > 
L2 ACK 
GP (Tame out. | ¡$ Ses A A E EVE ede eue 
| 
| 6P Response 
Type = RESPONSE 
Code = RC_SUCCESS 
| SeqNum = 178 cells 
| CellList = [(1,2), (2,2), (3,5)] locked 
X N O E --+ 
L2 ACK 


moe ted a rl a S m ut e >| 6P Timeout 


6P Confirmation 


| 
Type = CONFIRMATION 
Code = RC SUCCESS 
cells SeqNum - 178 
locked CellList = [(2,2), (3,5)] 
t-- | Henne = = - -- - - -- = - -- -- = - == - = - === === > X «--4 


Figure 5: An Example 3-Step 6P Transaction 


Wang, et al. Standards Track [Page 10] 


RFC 8480 6top Protocol (6P) November 2018 


In this example, the 3-step transaction occurs as follows: 
1. The SF running on node A determines that two extra cells need to 
be scheduled to node B. The SF uses a 3-step transaction, so it 


does not select candidate cells. 


2. Node A sends a 6P ADD Request to node B, indicating that it 
wishes to add two cells (the "NumCells" value), with an empty 
"CellList". This 6P ADD Request is link-layer acknowledged by 
node B. 


3. After having successfully sent the 6P ADD Request, node A starts 
a 6P Timeout to abort the transaction in the event that no 6P 
Response is received from node B. 


4. The SF running on node B selects three candidate cells and locks 
them. Node B sends back a 6P Response to node A, indicating the 
three cells it has selected. The response is link-layer 
acknowledged by node A. 


5. After having successfully sent the 6P Response, node B starts a 
6P Timeout to abort the transaction in the event that no 6P 
Confirmation is received from node A. 


6. The SF running on node A selects two cells from the CellList 
field in the 6P Response and locks them. Node A sends back a 6P 
Confirmation to node B, indicating the cells it selected. The 


confirmation is link-layer acknowledged by node B. 

7. Upon completion of the 6P Transaction, two cells from node A to 
node B have been added to the TSCH schedule of both nodes A 
and B. 


8. An inconsistency in the schedule can happen if the 6P Timeout 
xpires when the 6P Confirmation is in the air, if the last 
link-layer ACK for the 6P Confirmation is lost, or if one of the 
nodes is power-cycled during the transaction.  6P provides an 
inconsistency detection mechanism to cope with such situations; 
see Section 3.4.6.2 for details. 
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3.2. Message Format 
Seded 6top Information Element (IE) 


6P messages travel over a single hop. 6P messages are carried as 
payload of an 802.15.4 Payload Information Element (IE) [IEEE802154]. 
The messages are encapsulated within the Payload IE header. The 
Group ID is set to the IETF IE value defined in [RFC8137]. The 
content is encapsulated by a subtype ID, as defined in [RFC8137]. 


Since 6P messages are carried in IEs, IEEE bit/byte ordering applies. 
Bits within each field in the "6top IE" subtype are numbered from 0 
(leftmost and least significant) to k-1 (rightmost and most 
significant), where the length of the field is k bits. Fields that 
are longer than a single octet are copied to the packet in the order 
from the octet containing the lowest-numbered bits to the octet 
containing the highest-numbered bits (little endian). 


This document defines the 6top IE, a subtype of the IETF IE defined 
in [RFC8137], with subtype SUBID 6TOP. The subtype content of the 
6top IE is defined in Section 3.2.2. The length of the 6top IE 
content is variable. 


3.2.2. Generic 6P Message Format 
All 6P messages follow the generic format shown in Figure 6. 


Ï 2 3 

01234567890123 4 5-6 T 8.9 01 2:3 4.5. 6 7 8:90: 
—+-+-4+-+4+-+4+-4+-4+-4-4-4-4-4+-4+-4+-4+-4-4-4-4-4-4-4+-4+-4-4+ 
| Code | SFID | SeqNum | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Other Fields... 
+-+-+-+-+-+-+-+-+- 


Figure 6: Generic 6P Message Format 
6P Version (Version): The version of 6P. Only version 0 is defined 


in this document. Future specifications may define subsequent 
versions of 6P. 


Type (T): The type of message. The message types are defined in 
Section 6.2.2. 


Reserved (R): Reserved bits. These two bits SHOULD be set to zero 
when sending the message and MUST be ignored upon reception. 
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Code: The Code field contains a 6P command identifier when the 6P 
message has a Type value of REQUEST. Section 6.2.3 lists the 
6P command identifiers. The Code field contains a 6P return 
code when the 6P message has a Type value of RESPONSE or 
CONFIRMATION. Section 6.2.4 lists the 6P return codes. The 
same return codes are used in both 6P Response and 6P 
Confirmation messages. 


6top Scheduling Function Identifier (SFID): The identifier of the SF 
to use to handle this message. The SFID is defined in 
Section 4.1. 


SeqNum: The sequence number associated with the 6P Transaction. 
Used to match the 6P Request, 6P Response, and 6P Confirmation 
of the same 6P Transaction. The value of SeqNum MUST be 
different for each new 6P Request issued to the same neighbor 
and using the same SF. The SeqNum is also used to ensure 
consistency between the schedules of the two neighbors. 
Section 3.4.6 details how the SeqNum is managed. 


Other Fields: The list of other fields and how they are used are 
detailed in Section 3.3. 


6P Request, 6P Response, and 6P Confirmation messages for a given 
transaction MUST share the same Version, SFID, and SeqNum values. 


Future versions of the 6P message SHOULD maintain the format of the 
6P Version, Type, and Code fields for backward compatibility. 


3.2.3. 6P CellOptions 


An 8-bit 6P CellOptions bitmap is present in the following 6P 
Requests: ADD, DELETE, COUNT, LIST, and RELOCATE. The format and 
meaning of this field MAY be redefined by the SF; the routine that 
parses this field is therefore associated with a specific SF. 


o In the 6P ADD Request, the 6P CellOptions bitmap is used to 
Specify what type of cell to add. 


o In the 6P DELETE Request, the 6P CellOptions bitmap is used to 
Specify what type of cell to delete. 


o In the 6P RELOCATE Request, the 6P CellOptions bitmap is used to 
Specify what type of cell to relocate. 


o In the 6P COUNT and LIST Requests, the 6P CellOptions bitmap is 
used as a selector of a particular type of cells. 
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The content of the 6P CellOptions bitmap applies to all elements in 
the CellList field. The possible values of the 6P CellOptions are as 


follows: 


o TX = 1 (res 
macLinkTabl 


o RX = 1 (res 
macLinkTabl 


o S = 1 (resp 
the macLink 


Section 6.2.6 


p. 0) refers to macTxType = TRUE (resp. FALSE) in the 
e of 802.15.4 [IEEE802154]. 


p. 0) refers to macRxType = TRUE (resp. FALSE) in the 
e of 802.15.4. 


. 0) refers to macSharedType = TRUE (resp. FALSE) in 
Table of 802.15.4. 


provides the format of the 6P CellOptions bitmap; this 


format applies 
meaning of the 
RELOCATE Reque 
meaning of the 
Requests (unle 


unless redefined by the SF. Figure 7 shows the 

6P CellOptions bitmap for the 6P ADD, DELETE, and 
sts (unless redefined by the SF). Figure 8 shows the 
6P CellOptions bitmap for the 6P COUNT and LIST 
ss redefined by the SF). 


Note: Here, we assume that node A issues the 6P command to node B. 


+ RR E e a as 
CellOptions 
Value 


TX=1,RX=1,S=1 


+ a MES o aj ap — ——ÓM 


Wang, et al. 


+------------------------ === 5 = + 
The type of cells B adds/deletes/relocates to its 
schedule when receiving a 6P ADD/DELETE/RELOCATE 
Request from A 


HO O + 
Invalid combination RC_ERR is returned 

HO O + 
Add/delete/relocate RX cells at B (TX cells at A) 

$ Y O + 
Add/delete/relocate TX cells at B (RX cells at A) 

$ O + 
Add/delete/relocate TX|RX cells at B (and at A) 

HO + 
Invalid combination RC_ERR is returned 

$ Y + 


Add/delete/relocate RX|SHARED cells at B 
(TX| SHARED cells at A) 


Add/delete/relocate TX|SHARED cells at B 
(RX|SHARED cells at A) 


Add/delete/relocate TX|RX|SHARED cells at B 
(and at A) 
E + 


7: Meaning of the 6P CellOptions Bitmap for the 
6P ADD, DELETE, and RELOCATE Requests 
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Note: Here, we assume that node A issues the 6P command to node B. 


4R------------- 4R-----------------2---2--------------------------------- + 
CellOptions The type of cells B selects from its schedule when 
Value receiving a 6P COUNT or LIST Request from A, 

from all the cells B has scheduled with A 

4R------------- 4R--------------2---2-2---2---------------2----------------- + 

TX=0,RX=0,S=0| All cells 

4R------------- $ -- = = = 5-5 == + 
TX=1,RX=0,S=0| All cells marked as RX only 

4+------------- 4+------------------------------ == == = - = = = = = === + 
TX=0,RX=1,S=0| A cells marked as TX only 

4R------------- 4R---------------2--2------------------------------------ + 
TX=1,RX=1,S=0| A cells marked as TX and RX only 

4R------------- 4R---------------2--2---2----------------------2----------- + 
TX=0,RX=0,S=1| All cells marked as SHARED (regardless of TX, RX) 
4R------------- 4R-----------------2---2------------------------2--------- + 
TX=1,RX=0,S=1| All cells marked as RX and SHARED only 

4R------------- $ === === == = = = = = = = == + 
TX=0,RX=1,S=1| All cells marked as TX and SHARED only 

4R------------- $ -- === = 5 5-5-5 = + 
TX-1,RX-1,S-1| All cells marked as TX, RX, and SHARED 

4R------------- $ -- == == = = 5 5 == + 


Figure 8: Meaning of the 6P CellOptions Bitmap for the 
6P COUNT and LIST Requests 


The CellOptions constitute an opaque set of bits, sent unmodified to 


the SF. The SF MAY redefine the format and meaning of the 
CellOptions field. 


Wang, et al. Standards Track [Page 15] 


RFC 8480 6top Protocol (6P) November 2018 


3.2.4. 6P CellList 


A CellList field MAY be present in a 6P ADD Request, a 6P DELETE 
Request, a 6P RELOCATE Request, a 6P Response, or a 6P Confirmation. 
It is composed of a concatenation of zero or more 6P Cells as defined 
in Figure 9. The content of the CellOptions field specifies the 


options associated with all cells in the CellList. This necessarily 
means that the same options are associated with all cells in the 
CellList. 


A 6P Cell is a 4-byte field; its default format is: 
1 2 3 
0422345 67 8°9 0123456789012 3°45 67 8 9 0 1 
+-4+-+4+-4+-4+-+4+-4+-4+-4+-4+-4-4-4+-4+-4-4+-4+-4-4-4+-4+-4-4-4+-4+-4+-4+-4+-4+-4+-4+-4-4+ 
| slotOffset | channelOffset 
+-4+-+4+-4+-4+-+4+-4+-4-4+-4+-4-4+-4+-4+-4-4+-4+-4+-4-4+-4+-4-4+-4+-4-4-4+-+4+-4+-4-4+-4+-4+ 
Figure 9: 6P Cell Format 
slotOffset: The slot offset of the cell. 


channelOffset: The channel offset of the cell. 


The CellList is an opaque set of bytes, sent unmodified to the SF. 
The length of the CellList field is implicit and is determined by the 
IE Length field of the Payload IE header as defined in 802.15.4. The 
SF MAY redefine the format of the CellList field; the routine that 
parses this field is therefore associated with a specific SF. 
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3.3. 6P Commands and Operations 
3.3.1. Adding Cells 


Cells are added by using the 6P ADD command. The Type field (T) is 
set to REQUEST. The Code field is set to ADD. Figure 10 defines the 
format of a 6P ADD Request. 


1 2 3 

Oo 132845 1677 8.9. 0:12:23: 40:67 89:0: d De 34-5 6. 7 *8..9 0o T 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Version| T | R | Code | SFID | SeqNum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
| Metadata | CellOptions | NumCells 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
| CellList 
+-+-+-+-+-+-+-+-+- 


Figure 10: 6P ADD Request Format 


Metadata: Used as extra signaling to the SF. The contents of the 
Metadata field are an opaque set of bytes passed unmodified to 
the SF. The meaning of this field depends on the SF and is out 
of scope for this document. For example, Metadata can specify 
in which slotframe to add the cells. 


CellOptions: Indicates the options to associate with the cells to be 
added. If more than one cell is added (NumCells > 1), the same 
options are associated with each one. This necessarily means 


that if node A needs to add multiple cells with different 
options it needs to initiate multiple 6P ADD Transactions. 


NumCells: The number of additional cells node A wants to schedule to 
node B. 


CellList: A list of zero or multiple candidate cells. Its length is 
implicit and is determined by the Length field of the Payload 
IE header. 
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Figure 11 defines the format of a 6P ADD Response and Confirmation. 


1 2 3 
Q.1-2 3 4 5.6. 7 8-9.0.T 2-3,4 5 6 7'8 9 Q0 12 34.5 0 7 8 9/0 1 


dh O A TR RLME-BRÓE-RBMBRBE-RCAA 
|Version| T | R | Code | SFID | SeqNum 
+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| CellList 


+-+-+-+-+-+-+-+-+- 
Figure 11: 6P ADD Response and Confirmation Format 
CellList: A list of zero or more 6P Cells. 


Consider the topology in Figure 1; in this case, the SF on node A 
decides to add NumCells cells to node B. 


Node A's SF selects NumCandidate cells from its schedule. These are 
cells that are candidates to be scheduled with node B. The 
CellOptions field specifies the type of these cells. NumCandidate 
MUST be greater than or equal to NumCells. How many cells node A 
selects (NumCandidate) and how that selection is done are specified 
in the SF and are out of scope for this document. Node A sends a 6P 
ADD Request to node B that contains the CellOptions, the value of 
NumCells, and a selection of NumCandidate cells in the CellList. If 
the NumCandidate cells do not fit in a single packet, this operation 
MUST be split into multiple independent 6P ADD Requests, each for a 
subset of the number of cells that eventually need to be added. In 
the case of a 3-step transaction, the SF is responsible for ensuring 
that the returned Candidate CellList fits into the 6P Response. 


Upon receiving the request, node B checks to see whether the 
CellOptions are set to a valid value as noted by Figure 7. If this 
is not the case, a Response with code RC ERR is returned. If the 
number of cells in the received CellList in node B is smaller than 
NumCells, node B MUST return a 6P Response with the RC ERR CELLLIST 
code. Otherwise, node B's SF verifies which of the cells in the 
CellList it can install in node B's schedule, following the specified 
CellOptions field. How that selection is done is specified in the SF 
and is out of scope for this document. The verification can succeed 
(NumCells cells from the CellList can be used), fail (none of the 
cells from the CellList can be used), or partially succeed (fewer 
than NumCells cells from the CellList can be used). In all cases, 
node B MUST send a 6P Response that includes a return code set to 

RC SUCCESS and that specifies the list of cells that were Scheduled 
following the CellOptions field. That list can contain NumCells 
elements (succeed), 0 elements (fail), or between 0 and NumCells 
elements (partially succeed). 
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Upon receiving the response, node A adds the cells specified in the 
CellList according to the CellOptions field. 


3.3.2. Deleting Cells 


Cells are deleted by using the 6P DELETE command. The Type field (T) 
is set to REQUEST. The Code field is set to DELETE. Figure 12 
defines the format of a 6P DELETE Request. 


1 2 3 

0123456789 0123456789012345678901 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Version| T | R | Code | SFID | SeqNum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ + 
| Metadata | CellOptions | NumCells 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 
| CellList 
+-+-+-+-+-+-+-+-+- 


Figure 12: 6P DELETE Request Format 
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. 
Its format is the same as that in the 6P ADD command, but its 
content could be different. 
CellOptions: Indicates the options that need to be associated with 
the cells to delete. Only cells matching the CellOptions can 
be deleted. 


NumCells: The number of cells from the specified CellList the sender 
wants to delete from the schedule of both sender and receiver. 


CellList: A list of zero or more 6P Cells. Its length is determined 
by the Length field of the Payload IE header. 
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Figure 13 defines the format of a 6P DELETE Response and 
Confirmation. 


1 2 3 

01234567890123 456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Code | SFID | SeqNum | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| CellList 
+-+-+-+-+-+-+-+-+- 


Figure 13: 6P DELETE Response and Confirmation Format 
CellList: A list of zero or more 6P Cells. 


The behavior for deleting cells is equivalent to that of adding cells 
except that: 


o The nodes delete the cells they agree upon rather than adding 
them. 


o All cells in the CellList MUST already be scheduled between the 
two nodes and MUST match the CellOptions field. If node A puts 
cells in its CellList that are not already scheduled between th 
two nodes and match the CellOptions field, node B MUST reply with 
a RC ERR CELLLIST return code. 


o The CellList in a 6P Request (2-step transaction) or 6P Response 


(3-step transaction) MUST be empty, contain exactly NumCells 
cells, or contain more than NumCells cells. The case where the 
CellList is not empty but contains fewer than NumCells cells is 
not supported; the RC ERR CELLLIST code MUST be returned when the 
CellList contains fewer than NumCells cells. If the CellList is 
empty, the SF on the receiving node MUST choose NumCells cells 
Scheduled to the sender matching the CellOptions field and delete 


them. If the CellList contains more than NumCells cells, the SF 
on the receiving node chooses exactly NumCells cells from the 
CellList to delete. 
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3.3.3. Relocating Cells 


Cell relocation consists of moving a cell to a different 
[slotOffset,channelOffset] location in the schedule. The Type field 
(T) is set to REQUEST. The Code field is set to RELOCATE. Figure 14 
defines the format of a 6P RELOCATE Request. 


1 p 3 
Q0. 402—393 4 506-7 8.9750. 1 23 4:506 7-9: 9:0. 52 3.4 5.0 4 8 9: 0-1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 

Version| T | R | Code | SFID | SeqNum 

V—R—R—R--—----.—R—R-4——-—---—.—.-—4—4———--.-— 4-444 
Metadata | CellOptions | NumCells 

HA AAA A A O O O A A A A A O O O AO A A A O 4-44 


Relocation CellList PP 
+-+-4+-4+-+-+4+-4+-4+-+-4+-4+-+-4+-+-4+-+-4+-4+-4- 
Candidate CellList E 
+-+-4+-4+-+-4+-4+-+-+-4+-4+-+-4-+-4+-+-4+-4+-4- 


Figure 14: 6P RELOCATE Request Format 
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. 


CellOptions: Indicates the options that need to be associated with 
cells to be relocated. 


NumCells: The number of cells to relocate. MUST be greater than or 
equal to l. 


Relocation CellList: The list of NumCells 6P Cells to relocate. 


Candidate CellList: A list of NumCandidate candidate cells for 
node B to pick from. NumCandidate MUST be 0, equal to 
NumCells, or greater than NumCells. Its length is determined 
by the Length field of the Payload IE header. 


In a 2-step 6P RELOCATE Transaction, node A specifies both (1) the 
cells it needs to relocate and (2) the list of candidate cells to 
relocate to. The Relocation CellList MUST contain exactly NumCells 
entries. The Candidate CellList MUST contain at least NumCells 
entries (NumCandidate >= NumCells). 


In a 3-step 6P RELOCATE Transaction, node A specifies only the cells 
it needs to relocate -- not the list of candidate cells to relocate 
to. The Candidate CellList MUST therefore be empty. 
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Figure 15 defines the format of a 6P RELOCATE Response and 
Confirmation. 


1 2 3 
U 13 SF Sr 6 7 89212 $4350 7:8 9 0 E-3-4 5.6 7.8-9 0 t 
+—+-+-+-+-4+-4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Version| T | | Code | SFID | SeqNum | 
+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| CST TES qi 
+-+-+-+-+-+-+-+-+- 


Figure 15: 6P RELOCATE Response and Confirmation Format 
CellList: A list of zero or more 6P Cells. 


Node A's SF wants to relocate NumCells cells. Node A creates a 6P 
RELOCATE Request and indicates the cells it wants to relocate in the 
Relocation CellList. It also selects NumCandidate cells from its 
Schedule as candidate cells to relocate the cells to, and it puts 
them in the Candidate CellList. The CellOptions field specifies the 
type of the cell(s) to relocate. NumCandidate MUST be greater than 
or equal to NumCells. How many cells it selects (NumCandidate) and 
how that selection is done are specified in the SF and are out of 
Scope for this document. Node A sends the 6P RELOCATE Request to 
node B. 


Upon receiving the request, node B checks to see if the length of the 
Candidate CellList is greater than or equal to NumCells. Node B's SF 
verifies that all the cells in the Relocation CellList are scheduled 
with node A and are associated with the options specified in the 
CellOptions field. If either check fails, node B MUST send a 6P 
Response to node A with return code RC ERR CELLLIST. If both checks 
pass, node B's SF verifies which of the cells in the Candidate 
CellList it can install in its schedule. How that selection is done 
is specified in the SF and is out of scope for this document. That 
verification for the Candidate CellList can succeed (NumCells cells 
from the Candidate CellList can be used), fail (none of the cells 
from the Candidate CellList can be used), or partially succeed (fewer 
than NumCells cells from the Candidate CellList can be used). In all 
cases, node B MUST send a 6P Response that includes a return code set 
to RC SUCCESS and that specifies the list of cells that will be 
rescheduled following the CellOptions field. That list can contain 
NumCells elements (succeed), 0 elements (fail), or between 0 and 
NumCells elements (partially succeed). If N < NumCells cells appear 
in the CellList, this means that the first N cells in the Relocation 
CellList have been relocated and the remainder have not. 
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Upon receiving the response with code RC SUCCESS, node A relocates 
the cells specified in the Relocation CellList of its RELOCATE 
Request to the new locations specified in the CellList of the 6P 
Response, in the same order. If the received return code is 

RC ERR CELLLIST, the transaction is aborted and no cell is relocated. 
In the case of a 2-step transaction, node B relocates the selected 
cells upon receiving the link-layer ACK for the 6P Response. In the 
case of a 3-step transaction, node B relocates the selected cells 
upon receiving the 6P Confirmation. 


The SF SHOULD NOT relocate all cells between two nodes at the same 
time, as this might result in the schedules of both nodes diverging 
significantly. 


Figure 16 shows an example of a successful 2-step 6P RELOCATE 


Transaction. 
+---------- + +---------- + 
| Node A | | Node B 
+----+----- + +----- +----+ 
6P RELOCATE Request 
Type = REQUEST 
Code = RELOCATE 
SeqNum = II 
NumCells = 2 
R.CellList = [(1,2), (2,2)] 
C Ce ist = [ (3,3), (4,3), (5,3) ] 
SA O A ena ee ELEM >| B prepares 
L2 ACK to relocate 
<- ----------- - - - ee (1,2) ->(5,3) 
and 
(2,2) -> (3,3) 
6P Response 
Code = RC_SUCCESS 
SeqNum = 11 
CellList = [(5,3),(3,3)] 
A relocates |«&--------—------—---—-------—-------------- 
(1,2)->(5,3) L2 ACK 
and: | ¡+05 Sea? So Se Se ew So E >| B relocates 
(2,2)-»(3,3) (1,2)->(5,3) 
and 
(2,2) -» (3,3) 


Figure 16: Example of a Successful 2-Step 6P RELOCATE Transaction 
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Figure 17 shows an example of a partially successful 2-step 6P 
RELOCATE Transaction. 


6P RELOCATE Request 


Type = REQUEST 

Code = RELOCATE 
SeqNum = 199 

NumCells = 2 

R.CellList = [(1,2), (2,2)1 
C.CellList = 


B prepares 
to relocate 


L2 ACK (1,2)-»(4,3) 
A A C Ur eS E, er EX AES but cannot 
relocate (2,2) 
6P Response 
Type = RESPONSE 
Code = RC SUCCESS 
SeqNum = 199 
CellList = [(4,3)] 
A, FET OCALES: | SPS SSeS rsa tS 77 SSS SO 
(1,2) -> (4,3) L2 ACK 
AA A AA E A AZ B relocates 
(1,2) -» (4,3) 
Figure 17: Example of a Partially Successful 2-Step 6P 
RELOCATE Transaction 
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Figure 18 shows an example of a failed 2-step 6P RELOCATE 


Transaction. 
4---------- + 4---------- + 
| Node A | | Node B 
+----4----- + +----- +----+ 
6P RELOCATE Request 
Type = REQUEST 
Code = RELOCATE 
SeqNum = 53 
NumCells = 2 
R.CellList - [(1,2),(2,2)] 
C Ce List = [ (3,3), (4,3), (5,3) ] 
HPA ee ee ee ee eS >| B cannot 
L2 ACK relocate 
<- ----------- - - ee ee (1,2) 
or (2,2) 
6P Response 
Type = RESPONSE 
Code = RC_SUCCESS 
SeqNum = 53 
CellList = [] 
RSS RSS SSS a CSS SS SSS SaaS SSS SaaS B does not 
L2 ACK relocate 
A-does not. | S = 702 eee a RT eS AI ee > 
relocate 
Figure 18: Failed 2-Step 6P RELOCATE Transaction Example 


Wang, et al. Standards Track [Page 25] 


RFC 8480 6top Protocol (6P) November 2018 


Figure 19 shows an example of a successful 3-step 6P RELOCATE 


Wang, 


Transaction. 
4+---------- + 4+---------- + 
| Node A | | Node B 
+----4----- + +----- +----+ 
6P RELOCATE Request 
Type = REQUEST 
Code = RELOCATE 
SeqNum = 11 
NumCells = 2 
R.CellList = [(1,2),(2,2)] 
C.CellList = [] 
oe M — —— M O Á—M———— ÓÓÓ—Ó———— — E > 
L2 ACK 
LA Y A A E A Sr EAS B identifies 
candidate 
cells 
6P Response (3,3), 
Code = RC_SUCCESS (4,3), and 
SegNum = 11 (53) 
CellList = [(3,3), (4,3), (5,3) ] 
A Prepares 1|¡$==2=2=32=32225== 22222370 a pc 
to relocate L2 ACK 


(1,2)-» (5,3) 
and 
(2, 2)-»(3, 3) 


A relocates 
(1,2)-»(5,3) 

and 
(2, 2)-»(3, 3) 


Figure 19: 


et al. 


6P Confirmation 


Code 
SeqNum 
CellList 


RC SUCCESS 
11 
[(5,3), (3,3)] 


Standards Track 


B relocates 


(1,2)-» (5,3) 
and 
(2, 2)-»(3, 3) 


Example of a Successful 3-Step 6P RELOCATE Transaction 
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3.3.4. Counting Cells 


To retrieve the number of scheduled cells node A has with B, node A 
issues a 6P COUNT command. The Type field (T) is set to REQUEST. 

The Code field is set to COUNT. Figure 20 defines the format of a 6P 
COUNT Request. 


1 2 3 
0.1.2-3.4 5.67 8.9.0.1 2.3 4:5 6 18: 9.0.1 2 34 5.6 7 8 9 0-1 
dd + A dd O — + + + + + + ++ + - +++ ++ +++ -4—4—t -t 
|Version| T | | Code | SFID | SeqNum | 
dd 4 A q + + + e + + + + ++ + + +++ ++ ++ ++ ++ ++ 
| Metadata | CellOptions | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 


-+ 
R 
+ 


Figure 20: 6P COUNT Request Format 
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. 
Its format is the same as that in the 6P ADD command, but its 
content could be different. 


CellOptions: Specifies which type of cell to be counted. 


Figure 21 defines the format of a 6P COUNT Response. 


1 2 3 
0.1 2 3.4.5 6 7-8.9 0.1 2.39 4°95. 6-7 8990) 1 2.3 4.5 6 7T 8.9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ——— —— o ho + + 
|Version| T | R | Code | SFID | SeqNum 
E +++ 
| NumCells | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 21: 6P COUNT Response Format 


NumCells: The number of cells that correspond to the fields of the 
request. 


Node A issues a COUNT command to node B, specifying some cell 
options. Upon receiving the 6P COUNT Request, node B goes through 
its schedule and counts the number of cells scheduled with node A in 
its own schedule that match the cell options in the CellOptions field 
of the request. Section 3.2.3 details the use of the CellOptions 
field. 


Node B issues a 6P Response to node A with return code RC SUCCESS and 
with NumCells containing the number of cells that match the request. 
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3.3.5. Listing Cells 


To retrieve a list of scheduled cells node A has with node B, node A 
issues a 6P LIST command. The Type field (T) is set to REQUEST. The 
Code field is set to LIST. Figure 22 defines the format of a 6P LIST 
Request. 


1 2 3 
0. dL 2-39 4 506-7 8.950.101 2.3 4:506 7-9: 9:0. 52 3.4 5.0 4 8 9: 0-1 


Pd A A A + dh + d+ + + + q + + + + ++ +++ +++ + +++ 
|Version| T | R | Code | SFID | SeqNum 

Pd A A O + dh + q + q + + + + + ++ +++ +++ +++ +++ 
| Metadata | CellOptions | Reserved 

Pd A A O + dh + dd + q + + + + + ++ +++ +++ +++ +++ 
| Offset | MaxNumCells | 
PR A A O + ta tata dd + q + + q + + q + ++ +++ +++ + +++ 


Figure 22: 6P LIST Request Format 
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. 
Its format is the same as that in the 6P ADD command, but its 
content could be different. 


CellOptions:  Specifies which type of cell to be listed. 


Reserved: Reserved bits. These bits SHOULD be set to zero when 
sending the message and MUST be ignored upon reception. 


Offset: The offset of the first scheduled cell that is requested. 
The mechanism assumes that cells are ordered according to a 
rule defined in the SF. The rule MUST always order the cells 
in the same way. 


MaxNumCells: The maximum number of cells to be listed. Node B MAY 
return fewer than MaxNumCells cells -- for example, if 
MaxNumCells cells do not fit in the frame. 
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Figure 23 defines the format of a 6P LIST Response. 


1 p 3 
Q.L-2 3-4 5.6. 7.8 -9/.0.T 2-3,4 5 6 7:98 9 Q0 12 3 4.5 0 7 8 9/0 1 


VT RTRRRRÀBMETRR RR] RM 
|Version| T | R | Code | SFID | SeqNum 

dd A A A +++ 
| CellList 


+-+-+-+-+-+-+-+-+- 
Figure 23: 6P LIST Response Format 
CellList: A list of zero or more 6P Cells. 
When receiving a LIST command, node B returns the cells scheduled 


with A in its schedule that match the CellOptions field as specified 
in Section 3.2.3. 


When node B receives a LIST Request, the returned CellList in the 6P 
Response contains between 0 and MaxNumCells cells, starting from the 
specified offset. Node B SHOULD include as many cells as will fit in 


the frame. If the response contains the last cell, node B MUST set 
the Code field in the response to RC_EOL ("End of List", as per 
Figure 38 in Section 6.2.4), indicating to node A that there are no 


more cells that match the request. Node B MUST return at least one 
cell, unless the specified offset is beyond the end of B's cell list 
in its schedule. If node B has fewer than Offset cells that match 
the request, node B returns an empty CellList and a Code field set 
to RC EOL. 
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3.3.6. Clearing the Schedule 


To clear the schedule between nodes A and B (for example, after a 
Schedule inconsistency is detected), node A issues a CLEAR command. 
The Type field (T) is set to REQUEST. The Code field is set to 
CLEAR. Figure 24 defines the format of a 6P CLEAR Request. 


1 p 3 
ZE A 5067 8.950.123 4:506 7-9: O 2- 3.4 5.0 4 8 9: 0-1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P — o ++ + 
|Version| T | R | Code | SFID | SeqNum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| Metadata | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 24: 6P CLEAR Request Format 
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. 
Its format is the same as that in the 6P ADD command, but its 
content could be different. 


Figure 25 defines the format of a 6P CLEAR Response. 


1 2 3 
Q 1.2 3- 4.56 7:8 9 Q1 2 34.5:6:779-9 0 12.3 42:5 6 7'8 9. 0:1 


VRBEM RMRMRRR RETE RB] RM oo +++ 
|Version| T | R | Code | SFID | SeqNum 
VT +++ 


Figure 25: 6P CLEAR Response Format 


when a 6P CLEAR command is issued from node A to node B, both nodes A 
and B MUST remove all the cells scheduled between them. That is, 
node A MUST remove all the cells scheduled with node B, and node B 
MUST remove all the cells scheduled with node A. In a 6P CLEAR 
command, the SeqNum MUST NOT be checked. In particular, even if the 
request contains a SeqNum value that would normally cause node B to 
detect a schedule inconsistency, the transaction MUST NOT be aborted. 
Upon 6P CLEAR completion, the value of SeqNum MUST be reset to 0. 


The return code sent in response to a 6P CLEAR command SHOULD be 

RC SUCCESS unless the operation cannot be executed. When the CLEAR 
operation cannot be executed, the return code MUST be set to 

RC, RESET. 
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3.3.7. Generic Signaling between SFs 


The 6P SIGNAL message allows the SF implementations on two neighbor 
nodes to exchange generic commands. The payload in a received SIGNAL 
message is an opaque set of bytes passed unmodified to the SF. The 
length of the payload is determined by the Length field of the 
Payload IE header. How the generic SIGNAL command is used is 
Specified by the SF and is outside the scope of this document. The 
Type field (T) is set to REQUEST. The Code field is set to SIGNAL. 
Figure 26 defines the format of a 6P SIGNAL Request. 


1 2 3 
01234567890123456789012345678<901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Version| T | | Code | SFID | SeqNum | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Metadata | payload 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+ 
R 
+ 


Figure 26: 6P SIGNAL Request Format 
Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. 
Its format is the same as that in the 6P ADD command, but its 
content could be different. 


Figure 27 defines the format of a 6P SIGNAL Response. 


1 2 3 
OT 2345678 OL 2-3 4 56 7L 9-9 0'L2-3-4.5 6 7 Bs GOs 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- O A hh o o o o o + + 
[Version] T | R | Code | SFID | SeqNum 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
| payload 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 27: 6P SIGNAL Response Format 
3.4. Protocol Functional Details 
3.4.1. Version Checking 


All messages contain a Version field. If multiple protocol versions 
of 6P have been defined (in future specifications for Version values 
different from 0), a node MAY implement multiple protocol versions at 
the same time. When a node receives a 6P message with a version 
number it does not implement, the node MUST reply with a 6P Response 
with a return code field set to RC_ERR_VERSION. The format of this 
6P Response message MUST be compliant with version 0 and MUST be 
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supported by all future versions of the protocol. This ensures that 
when node B sends a 6P Response to node A indicating that it does not 
implement the 6P version in the 6P Request, node A can successfully 
parse that response. 


When a node supports a version number received in a 6P Request 
message, the Version field in the 6P Response MUST be the same as the 
Version field in the corresponding 6P Request. Similarly, in a 
3-step transaction, the Version field in the 6P Confirmation MUST 
match that of the 6P Request and 6P Response of the same transaction. 


3.4.2. SFID Checking 


All messages contain an SFID field. A node MAY support multiple SFs 
at the same time. When receiving a 6P message with an unsupported 
SFID, a node MUST reply with a 6P Response with a return code of 

RC ERR SFID. The SFID field in the 6P Response MUST be the same as 
the SFID field in the corresponding 6P Request. In a 3-step 
transaction, the SFID field in the 6P Confirmation MUST match that of 
the 6P Request and the 6P Response of the same transaction. 


3.4.3. Concurrent 6P Transactions 


Only a single 6P Transaction at a time in a given direction can take 


place between two neighbors. That is, a node MUST NOT issue a new 6P 
Request to a given neighbor before the previous 6P Transaction it 
initiated has finished (or possibly timed out). If a node receives a 


6P Request from a given neighbor before having sent the 6P Respons 

to the previous 6P Request from that neighbor, it MUST send back a 6P 
Response with a return code of RC RESET (as per Figure 38 in 

Section 6.2.4) and discard this ongoing second transaction. A node 
receiving a RC RESET code MUST abort the second transaction and treat 
it as though it never happened (i.e., reverting changes to the 
Schedule or SeqNum done by this transaction). 


Nodes A and B MAY support having two transactions going on at the 


same time, one in each direction. Similarly, a node MAY support 
concurrent 6P Transactions with different neighbors. In this case, 
the cells involved in an ongoing 6P Transaction MUST be "locked" 
until the transaction finishes. For example, in Figure 1, node C can 


have a different ongoing 6P Transaction with nodes B and R. Ifa 
node does not have enough resources to handle concurrent 6P 
Transactions from different neighbors, it MUST reply with a 6P 
Response with return code RC ERR BUSY (as per Figure 38 in 


Section 6.2.4). If the requested cells are locked, it MUST reply to 
that request with a 6P Response with return code RC ERR LOCKED (as 
per Figure 38). The node receiving RC ERR BUSY or RC ERR LOCKED MAY 


implement a retry mechanism as defined by the SF. 
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qud su. 6P Timeout 


A timeout occurs when the node that successfully sent a 6P Request 
does not receive the corresponding 6P Response within an amount of 
time specified by the SF. In a 3-step transaction, a timeout also 
occurs when a node sending the 6P Response does not receive a 6P 
Confirmation. When a timeout occurs, the transaction MUST be 
canceled at the node where the timeout occurs. The value of the 6P 
Timeout should be greater than the longest possible time it takes to 
receive the 6P Response or Confirmation. The value of the 6P Timeout 
hence depends on the number of cells scheduled between the neighbor 
nodes, the maximum number of link-layer retransmissions, etc. The SF 
MUST determine the value of the timeout. The value of the timeout is 
out of scope for this document. 


3.4.5. Aborting a 6P Transaction 


If the receiver of a 6P Request fails during a 6P Transaction and is 
unable to complete it, it SHOULD reply to that request with a 6P 
Response with return code RC RESET. Upon receiving this 6P Response, 
the initiator of the 6P Transaction MUST consider the 6P Transaction 
as having failed. 


Similarly, in the case of a 3-step transaction, when the receiver of 
a 6P Response fails during the 6P Transaction and is unable to 
complete it, it MUST reply to that 6P Response with a 6P Confirmation 
with return code RC RESET. Upon receiving this 6P Confirmation, the 
sender of the 6P Response MUST consider the 6P Transaction as having 
failed. 


3.4.6. SeqNum Management 


The SeqNum is the field in the 6top IE header used to match Request, 
Response, and Confirmation messages for a given transaction. The 
SeqNum is used to detect and handle duplicate commands 

(Section 3.4.6.1) and inconsistent schedules (Section 3.4.6.2). Each 
node remembers the last used SeqNum for each neighbor. That is, a 
node stores as many SeqNum values as it has neighbors. In the case 
of supporting multiple SFs at a time, a SeqNum value is maintained 
per SF and per neighbor. In the remainder of this section, we 
describe the use of SeqNum between two neighbors; the same happens 
for each other neighbor, independently. 


When a node resets, or after a CLEAR Transaction, it MUST reset 
SeqNum to 0. The 6P Response and 6P Confirmation for a transaction 
MUST use the same SeqNum value as that in the request. After every 
transaction, the SeqNum MUST be incremented by exactly 1. 
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Specifically, if node A receives the link-layer acknowledgment for 
its 6P Request, it will increment the SeqNum by exactly 1 after the 


6P Transaction ends. This ensures that, for the next 6P Transaction 
where it sends a 6P Request, the 6P Request will have a different 
SeqNum. 


Similarly, node B increments the SeqNum by exactly 1 after having 
received the link-layer acknowledgment for the 6P Response (2-step 6P 
Transaction) or after having sent the link-layer acknowledgment for 
the 6P Confirmation (3-step 6P Transaction). 


When node B receives a 6P Request from node A with SeqNum equal to O0, 
it checks the stored SeqNum for A. If A is a new neighbor, the 
Stored SeqNum in B will be 0. The transaction can continue. If the 
stored SeqNum for A in B is different than 0, a potential 
inconsistency is detected. In this case, B MUST return RC ERR SEQNUM 
with SeqNum-0. The SF of node A MAY decide what to do next, as 
described in Section 3.4.6.2. 


The SeqNum MUST be implemented as a lollipop counter: it rolls over 
from OxFF to 0x01 (not to 0x00). This is used to detect a neighbor 
reset. Figure 28 lists the possible values of the SeqNum. 
F----------- 4------------------------------ t 
| Value | Meaning | 
+----------- 4------------------------------ + 
| 0x00 | Clear, or after device reset | 
| OxO1-OxFF | Lollipop counter values | 
+----------- 4+------------------------------ + 


Figure 28: Possible Values of the SeqNum 


3.4.6.1. Detecting and Handling Duplicate 6P Messages 


All 6P commands are link-layer acknowledged. A duplicate message 
means that a node receives a second 6P Request, Response, or 
Confirmation. This happens when the link-layer acknowledgment is not 
received and a link-layer retransmission happens. Duplicate messages 
are normal and unavoidable. 
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Figure 29 shows an example 2-step transaction in which node A 
receives a duplicate 6P Response. 


4---------- + 4---------- + 
| Node A | | Node B 
T----4----- + 4----- +----+ 
6P Request (SeqNum=456) 
A Sa A A Ni a uit et a a ae et ied et a e ui a a e Sa a A: > 
L2 ACK 
< — ur ee ee ee ee ee 
6P Response (SeqNum=456) 
< A en ee ee a ee re ee eh ee 
L2 ACK 
Sas Sue Ste 1 oS X no ACK: 
link-layer 
6P Response  (SeqNum-456) retransmit 
duplicate: $ ====2223795 320225221294 52H 2 2 
6P Response L2 ACK 
received jJ FA DS SD See SS ee eS es > 


Figure 29: Example Duplicate 6P Message 
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Figure 30 shows an example 3-step transaction in which node A 
receives an out-of-order duplicate 6P Response after having sent a 6P 


Confirmation. 
4---------- t 4---------- + 
| Node A | | Node B 
4----4----- + 4----- +----+ 
6P Request (SeqNum=123) 
——^———————————————————————M > 
L2 ACK 
< t xmi eee oae queri EN xu Rs eek d See ae ee del] See Me SS ee | BEE 
6P Response  (SeqNum-123) 
« ———P————ÓÁ————Á——Á——— 
L2 ACK 
EM NCMO Se OA X no ACK: 
link-layer 
6P Confirmation  (SeqNum-123) retransmit 
A a > | 
L2 ACK | 
AA SRA SS Sie E se frame 
queued 
6P Response  (SeqNum-123) 
duplicate. |<se<ssSHssess ste estes setae eS ahs ssa ene <==+$ 
out-of-order L2 ACK 
6P Response: | === SoS eS eS eS SS SS RS Rev > 
received 


Figure 30: Example Out-of-Order Duplicate 6P Message 
A node detects a duplicate 6P message when it has the same SeqNum and 
type as the last frame received from the same neighbor. When 
receiving a duplicate 6P message, a node MUST send a link-layer 
acknowledgment but MUST silently ignore the 6P message at 6top. 


3.4.6.2. Detecting and Handling a Schedule Inconsistency 


A schedule inconsistency happens when the schedules of nodes A and B 


are inconsistent -- for example, when node A has a transmit cell to 
node B, but node B does not have the corresponding receive cell and 
therefore isn’t listening to node A on that cell. A schedule 


inconsistency results in loss of connectivity. 


The SeqNum field, which is present in each 6P message, is used to 
detect an inconsistency. The SeqNum field increments by 1 in each 
message, as detailed in Section 3.4.6. A node computes the expected 
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SeqNum field for the next 6P Transaction. If a node receives a 6P 
Request with a SeqNum value that is not the expected value, it has 
detected an inconsistency. 


There are two cases in which a schedule inconsistency happens. 


The first case is when a node loses state -- for example, when it is 
power-cycled (turned off, then on). In that case, its SeqNum value 
is reset to 0. Since the SeqNum is a lollipop counter, its neighbor 


detects an inconsistency in the next 6P Transaction. This is 
illustrated in Figures 31 and 32. 


4---------- + 4---------- + 

| Node A | | Node B | 

T----4----- + 4----- +----+ 
SeqNum=87 SeqNum=87 


6P Request (SeqNum=87) 


6P Response (SeqNum=87) 


==== power-cycle 
SeqNum-88 SeqNum-0 
6P Request (SeqNum-88) 


A O A AS >| Inconsistency 
L2 ACK detected 


6P Response (SeqNum-0, RC ERR SEQNUM) 


Figure 31: Example of Inconsistency Because Node B Resets 
(Detected by Node B) 
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4---------- t 4---------- + 
| Node A | Node B | 
+----+----- + +----- +----+ 
SeqNum-97 SeqNum-97 
6P Request  (SeqNum-97) 
SS SS eS SO A qe t A EIE ED n Lm > 
L2 ACK 
< ae = RY A — amu cce s mg ciun (qms meu mm, amu mE iem ae 
6P Response  (SeqNum-97) 
« —————————————— 
L2 ACK 
——————— ————————————À'——————————Á— > 
==== power-cycle 
SeqNum-98 SeqNum-0 
6P Request (SeqNum=0) 
Inconsistency |«&-------------------------------------- 
detected L2 ACK 
AAA £u eee a A A ce o cee EX > 
6P Response (SeqNum=0, RC_ERR_SEQNUM) 
——————————————————— —Ó— > 
L2 ACK 
< — A a a 


Figure 32: Example of Inconsistency Because Node B Resets 
(Detected by Node A) 
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The second case is when the maximum number of link-layer 


retransmissions is reached on th 


(or, 


equivalently, 


6P Respons 


This is illustrated in Figure 33. 


of a 2-step transaction 
on a 6P Confirmation of a 3-step transaction). 


4---------- + 4---------- + 
| Node A | | Node B | 
4----4----- + 4----- +----+ 
SeqNum=87 SeqNum=87 
6P Request (SeqNum=87 ) 
SSS SS Se A A Se M > 
L2 ACK 
< me” ee Re, AAA AAA SS ee A 
6P Response (SeqNum=87 ) 
< EE Toa Sam com yn A cr A a a i A E 
L2 ACK 
—-------c- x 
SeqNum-88 no ACK: 
6P Response  (SeqNum-87) retrans. 1 
(duplicate) [s===2========2===55==H==+=+5===2====5 
L2 ACK 
—-------c x 
no ACK: 
6P Respons (SeqNum-87) retrans. 2 
(duplicate). |€9-2-2—-592----55-H8-9-2--5-558s-2-0o2oneesoeoInesc 
L2 ACK 
—-------c- X 
max. retrans.: 
inconsistency 
detected 
Figure 33: Example Inconsistency Because of Maximum Link-Layer 


In both cases, 


If the inconsistency is detected during a 6P Transaction 


Retransmissions (where Maximum - 2) 


node B detects the inconsistency. 


(Figure 31), 


the node that has detected it MUST send back a 6P Response or 6P 


Confirmation with an error code of RC ERR SEQNUM. 
Response or 6P Confirmation, 
value of the sender of the message 
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The SF of the node that has detected the inconsistency MUST define 
how to handle the inconsistency. Three possible ways to do this are 
as follows: 

O Issue a 6P CLEAR Request to clear the schedule, and then rebuild. 


o Issue a 6P LIST Request to retrieve the schedule. 


o Internally "roll back" the schedule. 


How to handle an inconsistency is out of scope for this document. 
The SF defines how to handle an inconsistency. 


3.4.7. Handling Error Responses 


A return code marked as Yes in the "Is Error?" column in Figure 38 
(Section 6.2.4) indicates an error. When a node receives a 6P 
Response or 6P Confirmation with an error, it MUST consider the 6P 
Transaction as having failed. In particular, if this was a response 
to a 6P ADD, DELETE, or RELOCATE Request, the node MUST NOT add, 
delete, or relocate any of the cells involved in this 6P Transaction. 
Similarly, a node sending a 6P Response or a 6P Confirmation with an 
error code MUST NOT add, delete, or relocate any cells as part of 
that 6P Transaction. If a node receives an unrecognized return code, 
the 6P Transaction MUST be considered as having failed. In 
particular, in a 3-step 6P Transaction, when receiving a 6P Response 
with a return code that it does not recognize, the requester (node A) 
MUST send a 6P Confirmation to the responder (node B) with return 
code RC ERR and consider the transaction failed. Upon reception of a 
6P Confirmation with return code RC ERR, the responder MUST consider 
the transaction failed as well. Defining what to do after an error 
has occurred is out of scope for this document. The SF defines what 
to do after an error has occurred. 


3.5. Security 


6P messages MUST be secured through link-layer security. This is 
possible because 6P messages are carried as Payload IEs. 
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4. Requirements for 6top Scheduling Function (SF) Specifications 
4.1. SF Identifier (SFID) 


Each SF has a 1-byte identifier. Section 6.2.5 defines the rules for 
applying for an SFID. 


4.2. Requirements for an SF Specification 
The specification for an SF 
o MUST specify an identifier for that SF. 


o MUST specify the rule for a node to decide when to add/delete one 
or more cells to/on a neighbor. 


o MUST specify the rule for a transaction source to select cells to 
add to the CellList field in the 6P ADD Request. 


o MUST specify the rule for a transaction destination to select 
cells from the CellList to add to its schedule. 


o MUST specify a value for the 6P Timeout or a rule/equation to 
calculate it. 


o MUST specify the rule for ordering cells. 


o MUST specify a meaning for the Metadata field in the 6P ADD 
Request. 


o MUST specify the SF behavior of a node when it boots. 
o MUST specify how to handle a schedule inconsistency. 


o MUST specify what to do after an error has occurred (the node 
either sent a 6P Response with an error code or received one). 


o MUST specify the list of statistics to gather. Example statistics 
include the number of transmitted frames to each neighbor. If the 
SF does not require that statistics be gathered, the SF 
Specification MUST explicitly say so. 


o SHOULD clearly state the application domain the SF is created for. 


o SHOULD contain examples that highlight normal and error scenarios. 


o SHOULD contain a list of current implementations, at least during 
the Internet-Draft (I-D) state of the document, per [RFC7942]. 


Wang, et al. Standards Track [Page 41] 


RFC 8480 6top Protocol (6P) November 2018 


o SHOULD contain a performance evaluation of the scheme, possibly 
through references to external documents. 


o SHOULD define the format of the SIGNAL command payload and 
its use. 


o MAY redefine the format of the CellList field. 


o MAY redefine the format of the CellOptions field. 


o MAY redefine the meaning of the CellOptions field. 


5. Security Considerations 


6P messages are carried inside 802.15.4 Payload Information Elements 
(IES). Those Payload IEs are encrypted and authenticated at the link 
layer through CCM* [CCM-Star] ("CCM" stands for "Cipher block 
Chaining -- Message authentication code"). 6P benefits from the same 
level of security as any other Payload IE. 6P does not define its 
own security mechanisms. In particular, although a key management 
Solution is out of scope for this document, 6P will benefit from the 
key management solution used in the network. This is relevant, as 
security attacks such as forgery and misattribution attacks become 
more damaging when a single key is shared amongst a group of more 
than two participants. 


6P does not provide protection against DoS attacks. Example attacks 
include not sending confirmation messages in 3-step transactions and 
sending incorrectly formatted requests. These cases SHOULD be 


handled by an appropriate policy, such as rate-limiting or 
time-limited blacklisting of the attacker after several attempts. 
The effect on the overall network is mostly localized to the two 
nodes in question, as communication happens in dedicated cells. 
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6. IANA Considerations 


6.1. IETF IE Subtype 6P 


This document adds the following number to the "IEEE Std 802.15.4 
IETF IE Subtype IDs" registry defined by [RFC8137]: 


qucm $ RARO RAS + 
| Value | Subtype ID | Reference | 
Ho AZ HO + 
| 1 | SUBID_6TOP | RFC 8480 | 
e a ata A T A SS =5 25328 + 


Figure 34: IETF IE Subtype SUBID_6TOP 


6.2. 6TiSCH Parameters Subregistries 


This section defines subregistries within the "IPv6 Over the TSCH 
Mode of IEEE 802.15.4e (6TiSCH)" parameters registry, hereafter 
referred to as the "6TiSCH parameters" registry. Each subregistry is 
described in a subsection. 


6.2.1. 6P Version Numbers 
The name of the subregistry is "6P Version Numbers". 
The following note is included in this registry: "In the 6top 


Protocol (6P) [RFC8480], there is a field to identify the version of 
the protocol. This field is 4 bits in size." 


Each entry in the subregistry must include the version in the 
range 0-15 and a reference to the 6P version's documentation. 


The initial entry in this subregistry is as follows: 


4--------- 4----------- * 
| Version | Reference | 
4--------- 4----------- * 
| 0 | RFC 8480 | 
4--------- 4----------- + 


Figure 35: 6P Version Number Entry 
All other version numbers are Unassigned. 


The IANA policy for future additions to this subregistry is "IETF 
Review" or "IESG Approval" as described in [RFC8126]. 
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6.2.2. 6P Message Types 


The name of the subregistry is "6P Message Types". 


The following note is included in this registry: "In version 0 of the 
6top Protocol (6P) [RFC8480], there is a field to identify the type 
of message. This field is 2 bits in size." 


Each entry in the subregistry must include the message type in the 
range b00-b11, the corresponding name, and a reference to the 6P 
message type's documentation. 


Initial entries in this subregistry are as follows: 


+------ 4+-------------- +----------- + 
| Type | Name | Reference | 
+------ 4R-------------- 4R----------- + 
| b00 | REQUEST | RFC 8480 | 
| b01 | RESPONSE | RFC 8480 | 
| b10 | CONFIRMATION | RFC 8480 | 
+------ 4+-------------- 4R----------- + 


Figure 36: 6P Message Types 


All other message types are Unassigned. 


The IANA policy for future additions to this subregistry is "IETF 
Review" or "IESG Approval" as described in [RFC8126]. 


6.22 «35 6P Command Identifiers 


The name of the subregistry is "6P Command Identifiers". 


The following note is included in this registry: "In version 0 of the 
6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in 
Size. In a 6P Request, the value of this Code field is used to 


identify the command." 


Each entry in the subregistry must include an identifier in the 
range 0-255, the corresponding name, and a reference to the 6P 
command identifier's documentation. 
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Initial entries in this subregistry are as follows: 


+------------ 4+------------ 4+----------- + 
Identifier Name Reference 
4+------------ +------------ 4+----------- + 

0 Reserved RFC 8480 
1 ADD RFC 8480 
2 DELETE RFC 8480 
3 RELOCATE RFC 8480 
4 COUNT RFC 8480 
5 LIST RFC 8480 
6 SIGNAL RFC 8480 
7 CLEAR RFC 8480 
8-254 Unassigned 
255 Reserved RFC 8480 
+------------ 4+------------ 4+----------- + 


Figure 37: 6P Command Identifiers 


The IANA policy for future additions to this subregistry is "IETF 
Review" or "IESG Approval" as described in [RFC8126]. 


6:24 A 6P Return Codes 


The name of the subregistry is "6P Return Codes". 


The following note is included in this registry: "In version 0 of the 
6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in 
Size. In a 6P Response or 6P Confirmation, the value of this Code 


field is used to identify the return code." 


Each entry in the subregistry must include a return code in the 
range 0-255, the corresponding name, the corresponding description, 


and a reference to the 6P return code's documentation. If the return 
code corresponds to a Response error, the "Is Error?" entry must 
indicate "Yes". Otherwise, "No" must be used. 
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Initial entries in this subregistry are as follows: 


4------ 4----------------- 4--------------------------- 4----------- + 
Code Name Description Is Error? 
4------ 4----------------- 4--------------------------- 4----------- + 
0 RC_SUCCESS operation succeeded No 
1 RC_EOL end of list No 
2 RC_ERR generic error Yes 
3 RC_RESET critical error, reset Yes 
4 RC_ERR_VERSION unsupported 6P version Yes 
5 RC ERR SFID unsupported SFID Yes 
6 RC ERR SEQNUM Schedule inconsistency Yes 
7 RC ERR CELLLIST cellList error Yes 
8 RC ERR BUSY busy Yes 
9 RC ERR. LOCKED cells are locked Yes 

4------ 4----------------- 4--------------------------- +----------- + 


Figure 38: 6P Return Codes 
All other message types are Unassigned. 


The IANA policy for future additions to this subregistry is "IETF 
Review" or "IESG Approval" as described in [RFC8126]. 


6.2.5. 6P Scheduling Function Identifiers 
The name of the subregistry is "6P Scheduling Function Identifiers". 
The following note is included in this registry: "In version 0 of the 
6top Protocol (6P) [RFC8480], there is a field to identify the 


Scheduling Function to handle the message. This field is 8 bits 
in size." 


Each entry in the subregistry must include an SFID in the 
range 0-255, the corresponding name, and a reference to the 6P 
Scheduling Function’s documentation. 


There are currently no entries in this subregistry. 


4------ 4--------------------------------- 4-------------------------- + 
| SFID | Name | Reference 

4------ 4--------------------------------- 4-------------------------- + 
| 0-255| Unassigned | 

4------ 4--------------------------------- 4-------------------------- + 


Figure 39: SF Identifier (SFID) Entry 


All message types are Unassigned. 
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The IANA policy for future additions to this subregistry depends on 
the value of the SFID, as shown in Figure 40. These specifications 


must follow the guidelines of Section 4. 


T----------- a E T S + 

| Range | Registration Procedures | 

Ho $2 A A AA + 

| 0-127 | IETF Review or IESG Approval | 

| 128-255 | Expert Review 

toes SSeS RSS SSS SSS SSS ec SS SSeS SSS + 
Figure 40: SF Identifier (SFID): Registration Procedure 


6.2.6. 6P CellOptions Bitmap 
The name of the subregistry is "6P CellOptions Bitmap". 


included in this registry: "In version 0 of the 
CellOptions field 


The following note is 
6top Protocol (6P) [RFC8480], there is an optional 


that is 8 bits in size." 


Each entry in the subregistry must include a bit position in the 
range 0-7, the corresponding name, and a reference to the bit’s 


documentation. 


Initial entries in this subregistry are as follows: 


+----- 4--------------- 4----------- + 
| bit | Name | Reference | 
+----- +--------------- +----------- + 
| 0 | TX (Transmit) | RFC 8480 | 
| 1 | RX (Receive) | RFC 8480 | 
| 2 | SHARED | RFC 8480 | 
| 3-7 | Reserved | | 
+----- +--------------- +----------- + 


Figure 41: 6P CellOptions Bitmap 


All other message types are Unassigned. 


The IANA policy for future additions to this subregistry is "IETF 
Review" or "IESG Approval" as described in [RFC8126]. 
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